home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / bbs / rfc / rfcxxxx_8.lha / rfc1706 < prev    next >
Text File  |  1995-07-26  |  20KB  |  564 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         B. Manning
  8. Request for Comments: 1706                                           ISI
  9. Obsoletes: 1637, 1348                                         R. Colella
  10. Category: Informational                                             NIST
  11.                                                             October 1994
  12.  
  13.  
  14.                        DNS NSAP Resource Records
  15.  
  16.  
  17. Status of this Memo
  18.  
  19.    This memo provides information for the Internet community.  This memo
  20.    does not specify an Internet standard of any kind.  Distribution of
  21.    this memo is unlimited.
  22.  
  23. Abstract
  24.  
  25.    OSI lower layer protocols, comprising the connectionless network
  26.    protocol (CLNP) and supporting routing protocols, are deployed in
  27.    some parts of the global Internet.  Maintenance and debugging of CLNP
  28.    connectivity is greatly aided by support in the Domain Name System
  29.    (DNS) for mapping between names and NSAP addresses.
  30.  
  31.    This document defines the format of one new Resource Record (RR) for
  32.    the DNS for domain name-to-NSAP mapping. The RR may be used with any
  33.    NSAP address format.
  34.  
  35.    NSAP-to-name translation is accomplished through use of the PTR RR
  36.    (see STD 13, RFC 1035 for a description of the PTR RR). This paper
  37.    describes how PTR RRs are used to support this translation.
  38.  
  39.    This document obsoletes RFC 1348 and RFC 1637.
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Manning & Colella                                               [Page 1]
  59.  
  60. RFC 1706                      DNS NSAP RRs                  October 1994
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65.    OSI lower layer protocols, comprising the connectionless network
  66.    protocol (CLNP) [5] and supporting routing protocols, are deployed in
  67.    some parts of the global Internet.  Maintenance and debugging of CLNP
  68.    connectivity is greatly aided by support in the Domain Name System
  69.    (DNS) [7] [8] for mapping between names and NSAP (network service
  70.    access point) addresses [6] [Note: NSAP and NSAP address are used
  71.    interchangeably throughout this memo].
  72.  
  73.    This document defines the format of one new Resource Record (RR) for
  74.    the DNS for domain name-to-NSAP mapping. The RR may be used with any
  75.    NSAP address format.
  76.  
  77.    NSAP-to-name translation is accomplished through use of the PTR RR
  78.    (see RFC 1035 for a description of the PTR RR). This paper describes
  79.    how PTR RRs are used to support this translation.
  80.  
  81.    This memo assumes that the reader is familiar with the DNS. Some
  82.    familiarity with NSAPs is useful; see [1] or Annex A of [6] for
  83.    additional information.
  84.  
  85. 2.  Background
  86.  
  87.    The reason for defining DNS mappings for NSAPs is to support the
  88.    existing CLNP deployment in the Internet.  Debugging with CLNP ping
  89.    and traceroute has become more difficult with only numeric NSAPs as
  90.    the scale of deployment has increased. Current debugging is supported
  91.    by maintaining and exchanging a configuration file with name/NSAP
  92.    mappings similar in function to hosts.txt. This suffers from the lack
  93.    of a central coordinator for this file and also from the perspective
  94.    of scaling.  The former describes the most serious short-term
  95.    problem. Scaling of a hosts.txt-like solution has well-known long-
  96.    term scaling difficiencies.
  97.  
  98. 3.  Scope
  99.  
  100.    The methods defined in this paper are applicable to all NSAP formats.
  101.  
  102.    As a point of reference, there is a distinction between registration
  103.    and publication of addresses. For IP addresses, the IANA is the root
  104.    registration authority and the DNS a publication method. For NSAPs,
  105.    Annex A of the network service definition, ISO8348 [6], describes the
  106.    root registration authority and this memo defines how the DNS is used
  107.    as a publication method.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Manning & Colella                                               [Page 2]
  115.  
  116. RFC 1706                      DNS NSAP RRs                  October 1994
  117.  
  118.  
  119. 4.  Structure of NSAPs
  120.  
  121.    NSAPs are hierarchically structured to allow distributed
  122.    administration and efficient routing. Distributed administration
  123.    permits subdelegated addressing authorities to, as allowed by the
  124.    delegator, further structure the portion of the NSAP space under
  125.    their delegated control.  Accomodating this distributed authority
  126.    requires that there be little or no a priori knowledge of the
  127.    structure of NSAPs built into DNS resolvers and servers.
  128.  
  129.    For the purposes of this memo, NSAPs can be thought of as a tree of
  130.    identifiers. The root of the tree is ISO8348 [6], and has as its
  131.    immediately registered subordinates the one-octet Authority and
  132.    Format Identifiers (AFIs) defined there. The size of subsequently-
  133.    defined fields depends on which branch of the tree is taken. The
  134.    depth of the tree varies according to the authority responsible for
  135.    defining subsequent fields.
  136.  
  137.    An example is the authority under which U.S. GOSIP defines NSAPs [2].
  138.    Under the AFI of 47, NIST (National Institute of Standards and
  139.    Technology) obtained a value of 0005 (the AFI of 47 defines the next
  140.    field as being two octets consisting of four BCD digits from the
  141.    International Code Designator space [3]). NIST defined the subsequent
  142.    fields in [2], as shown in Figure 1. The field immediately following
  143.    0005 is a format identifier for the rest of the U.S. GOSIP NSAP
  144.    structure, with a hex value of 80. Following this is the three-octet
  145.    field, values for which are allocated to network operators; the
  146.    registration authority for this field is delegated to GSA (General
  147.    Services Administration).
  148.  
  149.    The last octet of the NSAP is the NSelector (NSel). In practice, the
  150.    NSAP minus the NSel identifies the CLNP protocol machine on a given
  151.    system, and the NSel identifies the CLNP user. Since there can be
  152.    more than one CLNP user (meaning multiple NSel values for a given
  153.    "base" NSAP), the representation of the NSAP should be CLNP-user
  154.    independent. To achieve this, an NSel value of zero shall be used
  155.    with all NSAP values stored in the DNS. An NSAP with NSel=0
  156.    identifies the network layer itself. It is left to the application
  157.    retrieving the NSAP to determine the appropriate value to use in that
  158.    instance of communication.
  159.  
  160.    When CLNP is used to support TCP and UDP services, the NSel value
  161.    used is the appropriate IP PROTO value as registered with the IANA.
  162.    For "standard" OSI, the selection of NSel values is left as a matter
  163.    of local administration. Administrators of systems that support the
  164.    OSI transport protocol [4] in addition to TCP/UDP must select NSels
  165.    for use by OSI Transport that do not conflict with the IP PROTO
  166.    values.
  167.  
  168.  
  169.  
  170. Manning & Colella                                               [Page 3]
  171.  
  172. RFC 1706                      DNS NSAP RRs                  October 1994
  173.  
  174.  
  175.               |--------------|
  176.               | <-- IDP -->  |
  177.               |--------------|-------------------------------------|
  178.               | AFI |  IDI   |            <-- DSP -->              |
  179.               |-----|--------|-------------------------------------|
  180.               | 47  |  0005  | DFI | AA |Rsvd | RD |Area | ID |Sel |
  181.               |-----|--------|-----|----|-----|----|-----|----|----|
  182.        octets |  1  |   2    |  1  | 3  |  2  | 2  |  2  | 6  | 1  |
  183.               |-----|--------|-----|----|-----|----|-----|----|----|
  184.  
  185.                     IDP    Initial Domain Part
  186.                     AFI    Authority and Format Identifier
  187.                     IDI    Initial Domain Identifier
  188.                     DSP    Domain Specific Part
  189.                     DFI    DSP Format Identifier
  190.                     AA     Administrative Authority
  191.                     Rsvd   Reserved
  192.                     RD     Routing Domain Identifier
  193.                     Area   Area Identifier
  194.                     ID     System Identifier
  195.                     SEL    NSAP Selector
  196.  
  197.                   Figure 1: GOSIP Version 2 NSAP structure.
  198.  
  199.  
  200.    In the NSAP RRs in Master Files and in the printed text in this memo,
  201.    NSAPs are often represented as a string of "."-separated hex values.
  202.    The values correspond to convenient divisions of the NSAP to make it
  203.    more readable. For example, the "."-separated fields might correspond
  204.    to the NSAP fields as defined by the appropriate authority (RARE,
  205.    U.S. GOSIP, ANSI, etc.). The use of this notation is strictly for
  206.    readability. The "."s do not appear in DNS packets and DNS servers
  207.    can ignore them when reading Master Files. For example, a printable
  208.    representation of the first four fields of a U.S. GOSIP NSAP might
  209.    look like
  210.  
  211.                              47.0005.80.005a00
  212.  
  213.    and a full U.S. GOSIP NSAP might appear as
  214.  
  215.              47.0005.80.005a00.0000.1000.0020.00800a123456.00.
  216.  
  217.    Other NSAP formats have different lengths and different
  218.    administratively defined field widths to accomodate different
  219.    requirements. For more information on NSAP formats in use see RFC
  220.    1629 [1].
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Manning & Colella                                               [Page 4]
  227.  
  228. RFC 1706                      DNS NSAP RRs                  October 1994
  229.  
  230.  
  231. 5.  The NSAP RR
  232.  
  233.    The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22
  234.    (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP
  235.    mapping in the DNS using the NSAP RR operates analogously to IP
  236.    address lookup. A query is generated by the resolver requesting an
  237.    NSAP RR for a provided domain name.
  238.  
  239.    NSAP RRs conform to the top level RR format and semantics as defined
  240.    in Section 3.2.1 of RFC 1035.
  241.  
  242.                                             1  1  1  1  1  1
  243.               0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  244.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  245.            |                                               |
  246.            /                                               /
  247.            /                        NAME                   /
  248.            |                                               |
  249.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  250.            |                    TYPE = NSAP                |
  251.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  252.            |                    CLASS = IN                 |
  253.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  254.            |                        TTL                    |
  255.            |                                               |
  256.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  257.            |                      RDLENGTH                 |
  258.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  259.            /                       RDATA                   /
  260.            /                                               /
  261.            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  262.  
  263.    where:
  264.  
  265.    *  NAME: an owner name, i.e., the name of the node to which this
  266.       resource record pertains.
  267.  
  268.    *  TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).
  269.  
  270.    *  CLASS: two octets containing the RR IN CLASS code of 1.
  271.  
  272.    *  TTL: a 32 bit signed integer that specifies the time interval in
  273.       seconds that the resource record may be cached before the source
  274.       of the information should again be consulted. Zero values are
  275.       interpreted to mean that the RR can only be used for the
  276.       transaction in progress, and should not be cached. For example,
  277.       SOA records are always distributed with a zero TTL to prohibit
  278.       caching. Zero values can also be used for extremely volatile data.
  279.  
  280.  
  281.  
  282. Manning & Colella                                               [Page 5]
  283.  
  284. RFC 1706                      DNS NSAP RRs                  October 1994
  285.  
  286.  
  287.    *  RDLENGTH: an unsigned 16 bit integer that specifies the length in
  288.       octets of the RDATA field.
  289.  
  290.    *  RDATA: a variable length string of octets containing the NSAP.
  291.       The value is the binary encoding of the NSAP as it would appear in
  292.       the CLNP source or destination address field. A typical example of
  293.       such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
  294.       20 (decimal); "."s have been omitted to emphasize that they don't
  295.       appear in the DNS packets.
  296.  
  297.                  39840f80005a0000000001e13708002010726e00
  298.  
  299.    NSAP RRs cause no additional section processing.
  300.  
  301. 6.  NSAP-to-name Mapping Using the PTR RR
  302.  
  303.    The PTR RR is defined in RFC 1035. This RR is typically used under
  304.    the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names.
  305.  
  306.    Similarly, the PTR RR is used to map from NSAPs to domain names under
  307.    the "NSAP.INT" domain. A domain name is generated from the NSAP
  308.    according to the rules described below. A query is sent by the
  309.    resolver requesting a PTR RR for the provided domain name.
  310.  
  311.    A domain name is generated from an NSAP by reversing the hex nibbles
  312.    of the NSAP, treating each nibble as a separate subdomain, and
  313.    appending the top-level subdomain name "NSAP.INT" to it. For example,
  314.    the domain name used in the reverse lookup for the NSAP
  315.  
  316.              47.0005.80.005a00.0000.0001.e133.ffffff000162.00
  317.  
  318.    would appear as
  319.  
  320.      0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \
  321.                          0.8.5.0.0.0.7.4.NSAP.INT.
  322.  
  323.    [Implementation note: For sanity's sake user interfaces should be
  324.    designed to allow users to enter NSAPs using their natural order,
  325.    i.e., as they are typically written on paper. Also, arbitrary "."s
  326.    should be allowed (and ignored) on input.]
  327.  
  328. 7.  Master File Format
  329.  
  330.    The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
  331.    conforms to Section 5, "Master Files," of RFC 1035. Below are
  332.    examples of the use of these RRs in Master Files to support name-to-
  333.    NSAP and NSAP-to-name mapping.
  334.  
  335.  
  336.  
  337.  
  338. Manning & Colella                                               [Page 6]
  339.  
  340. RFC 1706                      DNS NSAP RRs                  October 1994
  341.  
  342.  
  343.    The NSAP RR introduces a new hex string format for the RDATA field.
  344.    The format is "0x" (i.e., a zero followed by an 'x' character)
  345.    followed by a variable length string of hex characters (0 to 9, a to
  346.    f). The hex string is case-insensitive. "."s (i.e., periods) may be
  347.    inserted in the hex string anywhere after the "0x" for readability.
  348.    The "."s have no significance other than for readability and are not
  349.    propagated in the protocol (e.g., queries or zone transfers).
  350.  
  351.  
  352.    ;;;;;;
  353.    ;;;;;; Master File for domain nsap.nist.gov.
  354.    ;;;;;;
  355.  
  356.  
  357.    @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
  358.                                      1994041800   ; Serial  - date
  359.                                      1800         ; Refresh - 30 minutes
  360.                                      300          ; Retry   - 5 minutes
  361.                                      604800       ; Expire  - 7 days
  362.                                      3600 )       ; Minimum - 1 hour
  363.           IN     NS     emu.ncsl.nist.gov.
  364.           IN     NS     tuba.nsap.lanl.gov.
  365.    ;
  366.    ;
  367.    $ORIGIN nsap.nist.gov.
  368.    ;
  369.    ;     hosts
  370.    ;
  371.    bsdi1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
  372.             IN  A     129.6.224.161
  373.             IN  HINFO PC_486    BSDi1.1
  374.    ;
  375.    bsdi2    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
  376.             IN  A     129.6.224.162
  377.             IN  HINFO PC_486    BSDi1.1
  378.    ;
  379.    cursive  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
  380.             IN  A     129.6.224.171
  381.             IN  HINFO PC_386    DOS_5.0/NCSA_Telnet(TUBA)
  382.    ;
  383.    infidel  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
  384.             IN  A     129.6.55.164
  385.             IN  HINFO PC/486    BSDi1.0(TUBA)
  386.    ;
  387.    ;     routers
  388.    ;
  389.    cisco1   IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
  390.             IN  A     129.6.224.151
  391.  
  392.  
  393.  
  394. Manning & Colella                                               [Page 7]
  395.  
  396. RFC 1706                      DNS NSAP RRs                  October 1994
  397.  
  398.  
  399.             IN  A     129.6.225.151
  400.             IN  A     129.6.229.151
  401.    ;
  402.    3com1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
  403.             IN  A     129.6.224.111
  404.             IN  A     129.6.225.111
  405.             IN  A     129.6.228.111
  406.  
  407.  
  408.  
  409.  
  410.    ;;;;;;
  411.    ;;;;;; Master File for reverse mapping of NSAPs under the
  412.    ;;;;;;     NSAP prefix:
  413.    ;;;;;;
  414.    ;;;;;;          47.0005.80.005a00.0000.0001.e133
  415.    ;;;;;;
  416.  
  417.  
  418.    @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
  419.                                      1994041800   ; Serial  - date
  420.                                      1800         ; Refresh - 30 minutes
  421.                                      300          ; Retry   - 5 minutes
  422.                                      604800       ; Expire  - 7 days
  423.                                      3600 )       ; Minimum - 1 hour
  424.           IN     NS     emu.ncsl.nist.gov.
  425.           IN     NS     tuba.nsap.lanl.gov.
  426.    ;
  427.    ;
  428.    $ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT.
  429.    ;
  430.    0.0.1.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi1.nsap.nist.gov.
  431.    ;
  432.    0.0.2.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi2.nsap.nist.gov.
  433.    ;
  434.    0.0.1.7.1.0.0.0.f.f.f.f.f.f  IN    PTR  cursive.nsap.nist.gov.
  435.    ;
  436.    0.0.4.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  infidel.nsap.nist.gov.
  437.    ;
  438.    0.0.1.5.1.0.0.0.a.a.a.a.a.a  IN    PTR  cisco1.nsap.nist.gov.
  439.    ;
  440.    0.0.1.1.1.0.0.0.a.a.a.a.a.a  IN    PTR  3com1.nsap.nist.gov.
  441.  
  442. 8.  Security Considerations
  443.  
  444.    Security issues are not discussed in this memo.
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Manning & Colella                                               [Page 8]
  451.  
  452. RFC 1706                      DNS NSAP RRs                  October 1994
  453.  
  454.  
  455. 9.  Authors' Addresses
  456.  
  457.    Bill Manning
  458.    USC/Information Sciences Institute
  459.    4676 Admiralty Way
  460.    Marina del Rey, CA. 90292
  461.    USA
  462.  
  463.    Phone: +1.310.822.1511
  464.    EMail: bmanning@isi.edu
  465.  
  466.  
  467.    Richard Colella
  468.    National Institute of Standards and Technology
  469.    Technology/B217
  470.    Gaithersburg, MD 20899
  471.    USA
  472.  
  473.    Phone: +1 301-975-3627
  474.    Fax: +1 301 590-0932
  475.    EMail: colella@nist.gov
  476.  
  477. 10.  References
  478.  
  479.    [1] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines
  480.        for OSI NSAP Allocation inh the Internet", RFC 1629, NIST,
  481.        Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May
  482.        1994.
  483.  
  484.    [2] GOSIP Advanced Requirements Group.  Government Open Systems
  485.        Interconnection Profile (GOSIP) Version 2. Federal Information
  486.        Processing Standard 146-1, U.S. Department of Commerce, National
  487.        Institute of Standards and Technology, Gaithersburg, MD, April
  488.        1991.
  489.  
  490.    [3] ISO/IEC.  Data interchange - structures for the identification of
  491.        organization.  International Standard 6523, ISO/IEC JTC 1,
  492.        Switzerland, 1984.
  493.  
  494.    [4] ISO/IEC. Connection oriented transport protocol specification.
  495.        International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
  496.  
  497.    [5] ISO/IEC.  Protocol for Providing the Connectionless-mode Network
  498.        Service.  International Standard 8473, ISO/IEC JTC 1,
  499.        Switzerland, 1986.
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Manning & Colella                                               [Page 9]
  507.  
  508. RFC 1706                      DNS NSAP RRs                  October 1994
  509.  
  510.  
  511.    [6] ISO/IEC. Information Processing Systems -- Data Communications --
  512.        Network Service Definition.  International Standard 8348, ISO/IEC
  513.        JTC 1, Switzerland, 1993.
  514.  
  515.    [7] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
  516.        13, RFC 1034, USC/Information Sciences Institute, November 1987.
  517.  
  518.    [8] Mockapetris, P., "Domain Names -- Implementation and
  519.        Specification", STD 13, RFC 1035, USC/Information Sciences
  520.        Institute, November 1987.
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Manning & Colella                                              [Page 10]
  563.  
  564.